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FOREWORD 

This  publication,  “A  Guide  to  Understanding  Audit  in  Trusted  Systems,”  is  being  issued  by 
the  National  Computer  Security  Center  (NCSC)  under  the  authority  of  and  in  accordance  with 
Department  of  Defense  (DoD)  Directive  5215.1.  The  guidelines  described  in  this  document 
provide  a  set  of  good  practices  related  to  the  use  of  auditing  in  automatic  data  processing 
systems  employed  for  processing  classified  and  other  sensitive  information.  Recommendations 
for  revision  to  this  guideline  are  encouraged  and  will  be  reviewed  biannually  by  the  National 
Computer  Security  Center  through  a  formal  review  process.  Address  all  proposals  for  revision 
through  appropriate  channels  to: 

National  Computer  Security  Center 
9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755-6000 

Attention:  Chief,  Computer  Security  Technical  Guidelines 


28  July  1987 


National  Computer  Security  Center 


Director 
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PREFACE 


Throughout  this  guideline  there  will  be  recommendations  made  that  are  not  included  in  the 
Trusted  Computer  System  Evaluation  Criteria  (the  Criteria)  as  requirements.  Any  recommen¬ 
dations  that  are  not  in  the  Criteria  will  be  prefaced  by  the  word  “should,”  whereas  all 
requirements  will  be  prefaced  by  the  word  “shall.”  It  is  hoped  that  this  will  help  to  avoid  any 
confusion. 
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1.  INTRODUCTION 


1.1  History  of  the  National  Computer  Security  Center 

The  DoD  Computer  Security  Center  (DoDCSC)  was  established  in  January  1981  for  the 
purpose  of  expanding  on  the  work  started  by  the  DoD  Security  Initiative.  Accordingly,  the 
Director,  National  Computer  Security  Center,  has  the  responsibility  for  establishing  and 
publishing  standards  and  guidelines  for  all  areas  of  computer  security.  In  1985,  DoDCSC’s 
name  was  changed  to  the  National  Computer  Security  Center  to  reflect  its  responsibility  for 
computer  security  throughout  the  federal  government. 

1.2  Goal  of  the  National  Computer  Security  Center 

The  main  goal  of  the  National  Computer  Security  Center  is  to  encourage  the  widespread 
availability  of  trusted  computer  systems.  In  support  of  that  goal  a  metric  was  created,  the  DoD 
Trusted  Computer  System  Evaluation  Criteria  (the  Criteria),  against  which  computer  systems 
could  be  evaluated  for  security.  The  Criteria  was  originally  published  on  15  August  1983  as 
CSC-STD-001-83.  In  December  1985  the  DoD  adopted  it,  with  a  few  changes,  as  a  DoD 
Standard,  DoD  5200.28-STD.  DoD  Directive  5200.28,  “Security  Requirements  for  Automatic 
Data  Processing  (ADP)  Systems”  has  been  written  to,  among  other  things,  require  the 
Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  to  be  used  throughout 
the  DoD.  The  Criteria  is  the  standard  used  for  evaluating  the  effectiveness  of  security  controls 
built  into  ADP  systems.  The  Criteria  is  divided  into  four  divisions:  D,  C,  B,  and  A,  ordered 
in  a  hierarchical  manner  with  the  highest  division  (A)  being  reserved  for  systems  providing  the 
best  available  level  of  assurance.  Within  divisions  C  and  B  there  are  a  number  of  subdivisions 
known  as  classes,  which  are  also  ordered  in  a  hierarchical  manner  to  represent  different  levels 
of  security  in  these  classes. 


2.  PURPOSE 

For  Criteria  classes  C2  through  A1  the  Criteria  requires  that  a  user’s  actions  be  open  to 
scrutiny  by  means  of  an  audit.  The  audit  process  of  a  secure  system  is  the  process  of  recording, 
examining,  and  reviewing  any  or  all  security-relevant  activities  on  the  system.  This  guideline  is 
intended  to  discuss  issues  involved  in  implementing  and  evaluating  an  audit  mechanism.  The 
purpose  of  this  document  is  twofold.  It  provides  guidance  to  manufacturers  on  how  to  design 
and  incorporate  an  effective  audit  mechanism  into  their  system,  and  it  provides  guidance  to 
implementors  on  how  to  make  effective  use  of  the  audit  capabilities  provided  by  trusted 
systems.  This  document  contains  suggestions  as  to  what  information  should  be  recorded  on  the 
audit  trail,  how  the  audit  should  be  conducted,  and  what  protective  measures  should  be 
accorded  to  the  audit  resources. 

Any  examples  in  this  document  are  not  to  be  construed  as  the  only  implementations  that 
will  satisfy  the  Criteria  requirement.  The  examples  are  merely  suggestions  of  appropriate 
implementations.  The  recommendations  in  this  document  are  also  not  to  be  construed  as 
supplementary  requirements  to  the  Criteria.  The  Criteria  is  the  only  metric  against  which 
systems  are  to  be  evaluated. 

This  guideline  is  part  of  an  on-going  program  to  provide  helpful  guidance  on  Criteria  issues 
and  the  features  they  address. 


3.  SCOPE 

An  important  security  feature  of  Criteria  classes  C2  through  A1  is  the  ability  of  the  ADP 
system  to  audit  any  or  all  of  the  activities  on  the  system.  This  guideline  will  discuss  auditing 
and  the  features  of  audit  facilities  as  they  apply  to  computer  systems  and  products  that  are 
being  built  with  the  intention  of  meeting  the  requirements  of  the  Criteria. 
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4.  CONTROL  OBJECTIVES 


The  Trusted  Computer  System  Evaluation  Criteria  gives  the  following  as  the  Accountability 
Control  Objective: 

“Systems  that  are  used  to  process  or  handle  classified  or  other  sensitive  information 
must  assure  individual  accountability  whenever  either  a  mandatory  or  discretionary 
security  policy  is  invoked.  Furthermore,  to  assure  accountability  the  capability  must 
exist  for  an  authorized  and  competent  agent  to  access  and  evaluate  accountability 
information  by  a  secure  means,  within  a  reasonable  amount  of  time  and  without 
undue  difficulty.  ”[1] 

The  Accountability  Control  Objective  as  it  relates  to  auditing  leads  to  the  following  control 
objective  for  auditing: 

“A  trusted  computer  system  must  provide  authorized  personnel  with  the  ability  to 
audit  any  action  that  can  potentially  cause  access  to,  generation  of,  or  effect  the 
release  of  classified  or  sensitive  information.  The  audit  data  will  be  selectively  acquired 
based  on  the  auditing  needs  of  a  particular  installation  and/or  application.  However, 
there  must  be  sufficient  granularity  in  the  audit  data  to  support  tracing  the  auditable 
events  to  a  specific  individual  who  has  taken  the  actions  or  on  whose  behalf  the 
actions  were  taken.” [1] 


3 


5.  OVERVIEW  OF  AUDITING  PRINCIPLES 


Audit  trails  are  used  to  detect  and  deter  penetration  of  a  computer  system  and  to  reveal 
usage  that  identifies  misuse.  At  the  discretion  of  the  auditor,  audit  trails  may  be  limited  to 
specific  events  or  may  encompass  all  of  the  activities  on  a  system.  Although  not  required  by 
the  criteria,  it  should  be  possible  for  the  target  of  the  audit  mechanism  to  be  either  a  subject 
or  an  object.  That  is  to  say,  the  audit  mechanism  should  be  capable  of  monitoring  every  time 
John  accessed  the  system  as  well  as  every  time  the  nuclear  reactor  file  was  accessed;  and 
likewise  every  time  John  accessed  the  nuclear  reactor  file. 

5.1  Purpose  of  the  Audit  Mechanism 

The  audit  mechanism  of  a  computer  system  has  five  important  security  goals.  First,  the  audit 
mechanism  must  “allow  the  review  of  patterns  of  access  to  individual  objects,  access  histories 
of  specific  processes  and  individuals,  and  the  use  of  the  various  protection  mechanisms 
supported  by  the  system  and  their  effectiveness.” [2]  Second,  the  audit  mechanism  must  allow 
discovery  of  both  users’  and  outsiders’  repeated  attempts  to  bypass  the  protection  mechanisms. 
Third,  the  audit  mechanism  must  allow  discovery  of  any  use  of  privileges  that  may  occur  when 
a  user  assumes  a  functionality  with  privileges  greater  than  his  or  her  own,  i.e.,  programmer  to 
administrator.  In  this  case  there  may  be  no  bypass  of  security  controls  but  nevertheless  a 
violation  is  made  possible.  Fourth,  the  audit  mechanism  must  act  as  a  deterrent  against 
perpetrators’  habitual  attempts  to  bypass  the  system  protection  mechanisms.  However,  to  act 
as  a  deterrent,  the  perpetrator  must  be  aware  of  the  audit  mechanism’s  existence  and  its  active 
use  to  detect  any  attempts  to  bypass  system  protection  mechanisms.  The  fifth  goal  of  the  audit 
mechanism  is  to  supply  “an  additional  form  of  user  assurance  that  attempts  to  bypass  the 
protection  mechanisms  are  recorded  and  discovered.” [2]  Even  if  the  attempt  to  bypass  the 
protection  mechanism  is  successful,  the  audit  trail  will  still  provide  assurance  by  its  ability  to 
aid  in  assessing  the  damage  done  by  the  violation,  thus  improving  the  system’s  ability  to 
control  the  damage. 

5.2.  Users  of  the  Audit  Mechanism 

“The  users  of  the  audit  mechanism  can  be  divided  into  two  groups.  The  first  group  consists 
of  the  auditor,  who  is  an  individual  with  administrative  duties,  who  selects  the  events  to  be 
audited  on  the  system,  sets  up  the  audit  flags  which  enable  the  recording  of  those  events,  and 
analyzes  the  trail  of  audit  events.” [2]  In  some  systems  the  duties  of  the  auditor  may  be 
encompassed  in  the  duties  of  the  system  security  administrator.  Also,  at  the  lower  classes,  the 
auditor  role  may  be  performed  by  the  system  administrator.  This  document  will  refer  to  the 
person  responsible  for  auditing  as  the  system  security  administrator,  although  it  is  understood 
that  the  auditing  guidelines  may  apply  to  system  administrators  and/or  system  security 
administrators  and/or  a  separate  auditor  in  some  ADP  systems. 

“The  second  group  of  users  of  the  audit  mechanism  consists  of  the  system  users  themselves; 
this  group  includes  the  administrators,  the  operators,  the  system  programmers,  and  all  other 
users.  They  are  considered  users  of  the  audit  mechanism  not  only  because  they,  and  their 
programs,  generate  audit  events,”  [2]  but  because  they  must  understand  that  the  audit  mechanism 
exists  and  what  impact  it  has  on  them.  This  is  important  because  otherwise  the  user  deterrence 
and  user  assurance  goals  of  the  audit  mechanism  cannot  be  achieved. 
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5.3  Aspects  of  Effective  Auditing 

5.3. 1.  Identification/Authentication 

Logging  in  on  a  system  normally  requires  that  a  user  enter  the  specified  form  of  identification 
(e.g.,  login  ID,  magnetic  strip)  and  a  password  (or  some  other  mechanism)  for  authentication. 
Whether  this  information  is  valid  or  invalid,  the  execution  of  the  login  procedure  is  an  auditable 
event  and  the  identification  entered  may  be  considered  to  be  auditable  information.  It  is 
recommended  that  authentication  information,  such  as  passwords,  not  be  forwarded  to  the 
audit  trail.  In  the  event  that  the  identification  entered  is  not  recognized  as  being  valid,  the 
system  should  also  omit  this  identification  information,  but  should  audit  the  fact  that  an 
unsuccessful  attempt  was  made  to  access  the  system.  The  reason  for  this  is  that  a  user  may 
have  entered  a  password  when  the  system  expected  a  login  ID.  If  the  information  had  been 
written  to  the  audit  trail,  it  would  compromise  the  password  and  the  security  of  the  user. 

There  are,  however,  environments  where  the  risk  involved  in  recording  invalid  identification 
information  is  reduced.  In  systems  that  support  formatted  terminals,  the  likelihood  of  password 
entry  in  the  identification  field  is  markedly  reduced,  hence  the  recording  of  identification 
information  would  pose  no  major  threat.  The  benefit  of  recording  identification  information  is 
that  break-in  attempts  are  easier  to  detect  and  identifying  the  perpetrator  is  also  assisted.  The 
information  gathered  from  an  audit  may  be  necessary  for  any  legal  prosecution  that  may  follow 
a  security  violation. 

5.3.2  Administrative 

All  systems  rated  at  class  C2  or  higher  shall  have  audit  capabilities  and  personnel  designated 
as  responsible  for  the  audit  procedures.  For  the  C2  and  B1  classes,  the  duties  of  the  system 
operators  could  encompass  all  functions  including  those  of  the  auditor.  Starting  at  the  B2  class, 
there  is  a  requirement  for  the  TCB  to  support  separate  operator  and  administrator  functions. 
In  addition,  at  the  B3  class  and  above,  there  is  a  requirement  to  identify  the  system  security 
administrator  functions.  When  one  assumes  the  system  security  administrator  role  on  the 
system,  it  shall  be  after  taking  distinct  auditable  action,  e.g.,  login  procedure.  When  one  with 
the  privilege  of  assuming  the  role  is  on  the  system,  the  act  of  assuming  that  role  shall  also  be 
an  auditable  event. 

5. 3. 3  System  Design 

The  system  design  should  include  a  mechanism  to  invoke  the  audit  function  at  the  request 
of  the  system  security  administrator.  A  mechanism  should  also  be  included  to  determine  if  the 
event  is  to  be  selected  for  inclusion  as  an  audit  trail  entry.  If  pre-selection  of  events  is  not 
implemented,  then  all  auditable  events  should  be  forwarded  to  the  audit  trail.  The  Criteria 
requirement  for  the  administrator  to  be  able  to  select  events  based  on  user  identity  and/or 
object  security  classification  must  still  be  able  to  be  satisfied.  This  requirement  can  be  met  by 
allowing  post-selection  of  events  through  the  use  of  queries.  The  reduction  tool  that  is  used  to 
analyze  the  audit  trail  shall  be  provided  by  the  vendor. 

5.4  Security  of  the  Audit 

Audit  trail  software,  as  well  as  the  audit  trail  itself,  should  be  protected  by  the  Trusted 
Computing  Base  and  should  be  subject  to  strict  access  controls.  The  security  requirements  of 
the  audit  mechanism  are  the  following:  [2] 
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(1)  The  event  recording  mechanism  shall  be  part  of  the  TCB  and  shall  be  protected  from 
unauthorized  modification  or  circumvention. 

(2)  The  audit  trail  itself  shall  be  protected  by  the  TCB  from  unauthorized  access  (i.e., 
only  the  audit  personnel  may  access  the  audit  trail).  The  audit  trail  shall  also  be  protected  from 
unauthorized  modification. 

(3)  The  audit-event  enabling/disabling  mechanism  shall  be  part  of  the  TCB  and  shall  remain 
inaccessible  to  the  unauthorized  users. 

At  a  minimum,  the  data  on  the  audit  trail  should  be  considered  to  be  sensitive,  and  the  audit 
trail  itself  shall  be  considered  to  be  as  sensitive  as  the  most  sensitive  data  contained  in  the 
system. 

When  the  medium  containing  the  audit  trail  is  physically  removed  from  the  ADP  system,  the 
medium  should  be  accorded  the  physical  protection  required  for  the  highest  sensitivity  level  of 
data  contained  in  the  system. 
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6.  MEETING  THE  CRITERIA  REQUIREMENTS 

This  section  of  the  guideline  will  discuss  the  audit  requirements  in  the  Criteria  and  will 
present  a  number  of  additional  recommendations.  There  are  four  levels  of  audit  requirements. 
The  first  level  is  at  the  C2  Criteria  class  and  the  requirements  continue  evolving  through  the 
B3  Criteria  class.  At  each  of  these  levels,  the  guideline  will  list  some  of  the  events  which 
should  be  auditable,  what  information  should  be  on  the  audit  trail,  and  on  what  basis  events 
may  be  selected  to  be  audited.  All  of  the  requirements  will  be  prefaced  by  the  word  “shall,” 
and  any  additional  recommendations  will  be  prefaced  by  the  word  “should.” 

6.1  The  C2  Audit  Requirement 

6.1.1  Auditable  Events 

The  following  events  shall  be  subject  to  audit  at  the  C2  class: 

*  Use  of  identification  and  authentication  mechanisms 

*  Introduction  of  objects  into  a  user’s  address  space 

*  Deletion  of  objects  from  a  user’s  address  space 

*  Actions  taken  by  computer  operators  and  system  administrators  and/or  system  security 
administrators 

*  All  security-relevant  events  (as  defined  in  Section  5  of  this  guideline) 

*  Production  of  printed  output 

6.1.2  Auditable  Information 

The  following  information  shall  be  recorded  on  the  audit  trail  at  the  C2  class: 

*  Date  and  time  of  the  event 

*  The  unique  identifier  on  whose  behalf  the  subject  generating  the  event  was  operating 

*  Type  of  event 

*  Success  or  failure  of  the  event 

*  Origin  of  the  request  (e.g.,  terminal  ID)  for  identification/authentication  events 

*  Name  of  object  introduced,  accessed,  or  deleted  from  a  user’s  address  space 

*  Description  of  modifications  made  by  the  system  administrator  to  the  user/system  security 
databases 

6.1.3  Audit  Basis 

At  the  C2  level,  the  ADP  System  Administrator  shall  be  able  to  audit  based  on  individual 
identity. 

The  ADP  System  Administrator  should  also  be  able  to  audit  based  on  object  identity. 

6.2  The  B1  Audit  Requirement 

6.2.1  Auditable  Events 

The  Criteria  specifically  adds  the  following  to  the  list  of  events  that  shall  be  auditable  at  the 
B1  class: 

*  Any  override  of  human  readable  output  markings  (including  overwrite  of  sensitivity  label 
markings  and  the  turning  off  of  labelling  capabilities)  on  paged,  hard-copy  output  devices 

*  Change  of  designation  (single-level  to/from  multi-level)  of  any  communication  channel  or 
I/O  device 
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*  Change  of  sensitivity  level(s)  associated  with  a  single-level  communication  channel  or  1/ 
O  device 

*  Change  of  range  designation  of  any  multi-level  communication  channel  or  I/O  device  if 
a  specifiable  range  is  implemented 

6.2.2  A  udi table  In formation 

The  Criteria  specifically  adds  the  following  to  the  list  of  information  that  shall  be  recorded 
on  the  audit  trail  at  the  B1  class: 

*  Security  level  of  the  object 

The  following  information  should  also  be  recorded  on  the  audit  trail  at  the  B1  class: 

*  Subject  sensitivity  level 

6.2.3  Audit  Basis 

In  addition  to  previous  selection  criteria,  at  the  B1  level  the  Criteria  specifically  requires  that 
the  ADP  System  Administrator  shall  be  able  to  audit  based  on  individual  identity  and/or  object 
security  level. 

6.3  The  B2  Audit  Requirement 

6.3.1  Auditable  Events 

The  Criteria  specifically  adds  the  following  to  the  list  of  events  that  shall  be  auditable  at  the 
B2  class: 

*  Events  that  may  exercise  covert  storage  channels 

*  Change  of  range  designation  of  any  single-level  or  multi-level  communication  channel  or 
I/O  device 

6.3.2  A  udi  table  In formation 

No  new  requirements  have  been  added  at  the  B2  class. 

6.3.3  Audit  Basis 

In  addition  to  previous  selection  criteria,  at  the  B2  level  the  Criteria  specifically  requires  that 
“the  TCB  shall  be  able  to  audit  the  identified  events  that  may  be  used  in  the  exploitation  of 
covert  storage  channels.”  The  Trusted  Computing  Base  shall  audit  covert  storage  channels  that 
exceed  ten  bits  per  second.[l] 

The  Trusted  Computing  Base  should  also  provide  the  capability  to  audit  the  use  of  covert 
storage  mechanisms  with  bandwidths  that  may  exceed  a  rate  of  one  bit  in  ten  seconds. 

6.4  The  B3  Audit  Requirement 

6. 4. 1  Auditable  Events 

The  Criteria  specifically  adds  the  following  to  the  list  of  events  that  shall  be  auditable  at  the 
B3  class: 

*  Events  that  may  indicate  an  imminent  violation  of  the  system’s  security  policy  (e.g., 
exercise  covert  timing  channels) 
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6.4.2  Auditable  Information 

No  new  requirements  have  been  added  at  the  B3  class. 

6.4.3  Audit  Basis 

In  addition  to  previous  selection  criteria,  at  the  B3  level  the  Criteria  specifically  requires  that 
“the  TCB  shall  contain  a  mechanism  that  is  able  to  monitor  the  occurrence  or  accumulation 
of  security  auditable  events  that  may  indicate  an  imminent  violation  of  security  policy.  This 
mechanism  shall  be  able  to  immediately  notify  the  system  security  administrator  .when  thresholds 
are  exceeded  and,  if  the  occurrence  or  accumulation  of  these  security-relevant  events  continues, 
the  system  shall  take  the  least  disruptive  action  to  terminate  the  event. ”[1] 

Events  that  would  indicate  an  imminent  security  violation  would  include  events  that  utilize 
covert  timing  channels  that  may  exceed  a  rate  of  ten  bits  per  second  and  any  repeated 
unsuccessful  login  attempts. 

Being  able  to  immediately  notify  the  system  security  administrator  when  thresholds  are 
exceeded  means  that  the  mechanism  shall  be  able  to  recognize,  report,  and  respond  to  a 
violation  of  the  security  policy  more  rapidly  than  required  at  lower  levels  of  the  Criteria,  which 
usually  only  requires  the  System  Security  Administrator  to  review  an  audit  trail  at  some  time 
after  the  event.  Notification  of  the  violation  “should  be  at  the  same  priority  as  any  other  TCB 
message  to  an  operator.” [5] 

“If  the  occurrence  or  accumulation  of  these  security-relevant  events  continues,  the  system 
shall  take  the  least  disruptive  action  to  terminate  the  event.” [1]  These  actions  may  include 
locking  the  terminal  of  the  user  who  is  causing  the  event  or  terminating  the  suspect’s 
process(es).  In  general,  the  least  disruptive  action  is  application  dependent  and  there  is  no 
requirement  to  demonstrate  that  the  action  is  the  least  disruptive  of  all  possible  actions.  Any 
action  which  terminates  the  event  is  acceptable,  but  halting  the  system  should  be  the  last 
resort. 

6.5  The  AT  Audit  Requirement 

6. 5. 1  Auditable  Events 

No  new  requirements  have  been  added  at  the  A1  class. 

6.5.2  A  uditable  In formation 

No  new  requirements  have  been  added  at  the  A1  class. 

6.5.3  Audit  Basis 

No  new  requirements  have  been  added  at  the  A1  class. 


POSSIBLE  IMPLEMENTATION  METHODS 


7.  *  _ _ 

The  techniques  for  implementing  the  audit  requirements  will  vary  from  s7ste®  t0  ^Ste® 
depending  upon  the  characteristics  of  the  software,  firmware,  and  hardware  involved  and  any 
optional  features  that  are  to  be  available.  Technologically  advanced  techniques  that  are  available 
should  be  used  to  the  best  advantage  in  the  system  design  to  provide  the  requisite  security  as 
well  as  cost-effectiveness  and  performance. 

7.1  Pre/Post  Selection  of  Auditable  Events 

There  is  a  requirement  at  classes  C2  and  above  that  all  security-relevant  events  be  auttabte. 
However,  these  events  may  or  may  not  always  be  recorded  on  the  audit  trail.  Options  that  may 
be  exercised  in  selecting  which  events  should  be  audited  include  a  pre-selection  feature  and  a 
post-selection  feature.  A  system  may  choose  to  implement  both  options,  a  pre-selection  option 

0I1If ' a  systemS de velo per  chooses  not  to  implement  a  general  pre/post  selection  option,  there  is 
still  a  requirement  to?  allow  the  administrator  to  selectively  audit  the  actions ,  of  specified  use. 
for  all  Criteria  classes.  Starting  at  the  B1  class,  the  administrator  shall  also  be  able  to  audi 

based  on  object  security  level.  _ 

There  should  be  options  to  allow  selection  by  either  individuals  or  groups  of  users,  For 
example,  the  administrator  may  select  events  related  to  a  specified  individual  or  select  events 
related  to  individuals  included  in  a  specified  group.  Also,  the  administrator  may  specify  that 
events  related  to  the  audit  file  be  selected  or,  at  classes  B1  and  above,  that  accesses  to  objects 
with  a  given  sensitivity  level,  such  as  Top  Secret,  be  selected. 

7. 1. 1  Pre-Selection 

For  each  auditable  event  the  TCB  should  contain  a  mechanism  to  indicate  if  the  event  is  to 
be  recorded  on  the  audit  trail.  The  system  security  administrator  or  designee  shall  be  the  only 
person  authorized  to  select  the  events  to  be  recorded.  Pre-selection  may  be  by  user(s)  identity, 
and  at  the  B1  class  and  above,  pre-selection  may  also  be  possible  by  object  security  eve  . 
Although  the  system  security  administrator  shall  be  authorized  to  select  which  events  are  to  e 
recorded,  the  system  security  administrator  should  not  be  able  to  exclude  himself  from  eing 

Although  it  would  not  be  recommended,  the  system  security  administrator  may  have  the 
capability  to  select  that  no  events  be  recorded  regardless  of  the  Criteria  requirements.  The 
intention  here  is  to  provide  flexibility.  The  purpose  of  designing  audit  features  into  a  system  is 
not  to  impose  the  Criteria  on  users  that  may  not  want  it,  but  merely  to  provide  the  capability 
to  implement  the  requirements. 

A  disadvantage  of  pre-selection  is  that  it  is  very  hard  to  predict  what  events  may  be  of 
security-relevant  interest  at  a  future  date.  There  is  always  the  possibility  that  events  not  pre¬ 
selected  could  one  day  become  security-relevant,  and  the  potential  loss  from  not  auditing  ese 
events  would  be  impossible  to  determine. 

The  advantage  of  pre-selection  could  possibly  be  better  performance  as  a  result  of  not 
auditing  all  the  events  on  the  system. 

7.1.2  Post-Selection 

If  the  post-selection  option  to  select  only  specified  events  from  an  existing  audit  trail  is 
implemented,  again,  only  authorized  personnel  shall  be  able  to  make  this  selection.  Inclusion 
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of  this  option  requires  that  the  system  should  have  trusted  facilities  (as  described  in  section 
9.1)  to  accept  query/retrieval  requests,  to  expand  any  compressed  data,  and  to  output  the 
requested  data. 

The  main  advantage  of  post-selection  is  that  information  that  may  prove  useful  in  the  future 
is  already  recorded  on  an  audit  trail  and  may  be  queried  at  any  time. 

The  disadvantage  involved  in  post-selection  could  possibly  be  degraded  performance  due  to 
the  writing  and  storing  of  what  could  possibly  be  a  very  large  audit  trail. 

7.2  Data  Compression 

“Since  a  system  that  selects  all  events  to  be  audited  may  generate  a  large  amount  of  data,  it 
may  be  necessary  to  encode  the  data  to  conserve  space  and  minimize  the  processor  time 
required”  to  record  the  audit  records. [3]  If  the  audit  trail  is  encoded,  a  complementary 
mechanism  must  be  included  to  decode  the  data  when  required.  The  decoding  of  the  audit  trail 
may  be  done  as  a  preprocess  before  the  audit  records  are  accessed  by  the  database  or  as  a 
postprocess  after  a  relevant  record  has  been  found.'  Such  decoding  is  necessary  to  present  the 
data  in  an  understandable  form  both  at  the  administrators  terminal  and  on  batch  reports.  The 
cost  of  compressing  the  audit  trail  would  be  the  time  required  for  the  compression  and 
expansion  processes.  The  benefit  of  compressing  data  is  the  savings  in  storage  and  the  savings 
in  time  to  write  the  records  to  the  audit  trail. 

7.3  Multiple  Audit  Trails 

All  events  included  on  the  audit  trail  may  be  written  as  part  of  the  same  audit  trail,  but 
some  systems  may  prefer  to  have  several  distinct  audit  trails,  e.g.,  one  would  be  for  “user” 
events,  one  for  “operator”  events,  and  one  for  “system  security  administrator”  events.  This 
would  result  in  several  smaller  trails  for  subsequent  analysis.  In  some  cases,  however,  it  may 
be  necessary  to  combine  the  information  from  the  trails  when  questionable  events  occur  in 
order  to  obtain  a  composite  of  the  sequence  of  events  as  they  occurred.  In  cases  where  there 
are  multiple  audit  trails,  it  is  preferred  that  there  be  some  accurate,  or  at  least  synchronized, 
time  stamps  across  the  multiple  logs. 

Although  the  preference  for  several  distinct  audit  trails  may  be  present,  it  is  important  to 
note  that  it  is  often  more  useful  that  the  TCB  be  able  to  present  all  audit  data  as  one 
comprehensive  audit  trail. 

7.4  Physical  Storage 

A  factor  to  consider  in  the  selection  of  the  medium  to  be  used  for  the  audit  trail  would  be 
the  expected  usage  of  the  system.  The  I/O  volume  for  a  system  with  few  users  executing  few 
applications  would  be  quite  different  from  that  of  a  large  system  with  a  multitude  of  users 
performing  a  variety  of  applications.  In  any  case,  however,  the  system  should  notify  the  system 
operator  or  administrator  when  the  audit  trail  medium  is  approaching  its  storage  capacity. 
Adequate  advance  notification  to  the  operator  is  especially  necessary  if  human  intervention  is 
required. 

If  the  audit  trail  storage  medium  is  saturated  before  it  is  replaced,  the  operating  system  shall 
detect  this  and  take  some  appropriate  action  such  as: 

1.  Notifying  the  operator  that  the  medium  is  “full”  and  action  is  necessary.  The  system  should 

then  stop  and  require  rebooting.  Although  a  valid  option,  this  action  creates  a  severe  threat 

of  denial-of-service  attacks. 
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2  Storing  the  current  audit  records  on  a  temporary  medium  with  the  intention  of  later 
*  migration  to  the  normal  operational  medium,  thus  allowing  auditing  to  continue.  This 
temporary  storage  medium  should  be  afforded  the  same  protection  as  the  regular  audit 
storage  medium  in  order  to  prevent  any  attempts  to  tamper  with  it. 

3.  Delaying  input  of  new  actions  and/or  slowing  down  current  operations  to  prevent  any  action 
that  requires  use  of  the  audit  mechanism. 

4.  Stopping  until  the  administrative  personnel  make  more  space  available  for  writing  audit 
records. 

5.  Stopping  auditing  entirely  as  a  result  of  a  decision  by  the  system  security  administrator. 

Any  action  that  is  taken  in  response  to  storage  overflow  shall  be  audited.  There  is,  however, 
a  case  in  which  the  action  taken  may  not  be  audited  that  deserves  mention.  It  is  possible  to 
have  the  system  security  administrator’s  decisions  embedded  in  the  system  logic.  Such  pre¬ 
programmed  choices,  embedded  in  the  system  logic,  may  be  triggered  automatically  and  this 

action  may  not  be  audited. 

Still  another  consideration  in  the  selection  of  the  medium  to  be  used  is  the  speed  at  which 
the  medium  operates.  It  should  be  able  to  accommodate  the  “worst  case”  condition  such  as 
when  there  are  a  large  number  of  users  on  the  system  and  all  auditable  events  are  to  be 
recorded.  This  worst  case  rate  should  be  estimated  during  the  system  design  phase  and  (when 
possible)  suitable  hardware  should  be  selected  for  this  purpose. 

Regardless  of  how  the  system  handles  audit  trail  overflow,  there  must  be  a  way  to  archive 
all  of  the  audit  data. 

7.5  Write-Once  Device 

For  the  lower  Criteria  classes  (e.g.,  C2,  Bl)  the  audit  trail  may  be  the  major  tool  used  in 
detecting  security  compromises.  Implicit  in  this  is  that  the  audit  resources  should  provide  the 
maximum  protection  possible.  One  technique  that  may  be  employed  to  protect  the  audit  trail 
is  to  record  it  on  a  mechanism  designed  to  be  a  write-only  device.  Other  choices  would  be  to 
set  the  designated  device  to  write-once  mode  by  disabling  the  read  mechanism.  This  method 
could  prevent  an  attacker  from  erasing  or  modifying  the  data  already  written  on  the  audit  trail 
because  the  attacker  will  not  be  able  to  go  back  and  read  or  find  the  data  that  he  or  she  wishes 
to  modify. 

If  a  hardware  device  is  available  that  permits  only  the  writing  of  data  on  a  medium, 
modification  of  data  already  recorded  would  be  quite  difficult.  Spurious  messages  could  be 
written,  but  to  locate  and  modify  an  already  recorded  message  would  be  difficult.  Use  of  a 
write-once  device  does  not  prevent  a  penetrator  from  modifying  audit  resources  in  memory, 
including  any  buffers,  in  the  current  audit  trail. 

If  a  write-once  device  is  used  to  record  the  audit  trail,  the  medium  can  later  be  switched  to 
a  compatible  read  device  to  allow  authorized  personnel  to  analyze  the  information  on  the  audit 
trail  in  order  to  detect  any  attempts  to  penetrate  the  system.  If  a  penetrator  modified  the  audit 
software  to  prevent  writing  records  on  the  audit  trail,  the  absence  of  data  during  an  extended 
period  of  time  would  indicate  a  possible  security  compromise.  The  disadvantage  of  using  a 
write-once  device  is  that  it  necessitates  a  delay  before  the  audit  trail  is  available  for  analysis  by 
the  administrator.  This  may  be  offset  by  allowing  the  system  security  administrator  to  review 
the  audit  trail  in  real-time  by  getting  copies  of  all  audit  records  on  their  way  to  the  device. 
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7.6  Forwarding  Audit  Data 

If  the  facilities  are  available,  another  method  of  protecting  the  audit  trail  would  be  to 
forward  it  to  a  dedicated  processor.  The  audit  trail  should  then  be  more  readily  available  for 
analysis  by  the  system  security  administrator. 
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8.  OTHER  TOPICS 


8.1  Audit  Data  Reduction 

Depending  upon  the  amount  of  activity  on  a  system  and  the  audit  selection  process  used, 
the  audit  trail  size  may  vary.  It  is  a  safe  assumption  though,  that  the  audit  trail  would  grow  to 
sizes  that  would  necessitate  some  form  of  audit  data  reduction.  The  data  reduction  tool  would 
most  likely  be  a  batch  program  that  would  interface  to  the  system  security  administrator.  This 
batch  run  could  be  a  combination  of  database  query  language  and  a  report  generator  with  the 
input  being  a  standardized  audit  file. 

Although  they  are  not  necessarily  part  of  the  TCB,  the  audit  reduction  tools  should  be 
maintained  under  the  same  configuration  control  system  as  the  remainder  of  the  system. 


8.2  Availability  of  Audit  Data 

In  standard  data  processing,  audit  information  is  recorded  as  it  occurs.  Although  most 
information  is  not  required  to  be  immediately  available  for  real-time  analysis,  the  system 
security  administrator  should  have  the  capability  to  retreive  audit  information  within  minutes 
of  its  recording.  The  delay  between  recording  audit  information  and  making  it  available  for 
analysis  should  be  minimal,  in  the  range  of  several  minutes. 

For  events  which  do  require  immediate  attention,  at  the  B3  class  and  above,  an  alert  shall 
be  sent  out  to  the  system  security  administrator.  In  systems  that  store  the  audit  trail  in  a 
buffer,  the  system  security  administrator  should  have  the  capability  to  cause  the  buffer  to  be 
written  out.  To  which  device  to  send  the  real-time  alert  is  system  dependent. 


8.3  Audit  Data  Retention 

The  exact  period  of  time  required  for  retaining  the  audit  trail  is  site  dependent  and  should 
be  documented  in  the  site’s  operating  procedures  manual.  When  trying  to  arrive  at  the  optimum 
time  for  audit  trail  retention,  any  time  restrictions  on  the  storage  medium  should  be  considered. 
The  storage  medium  used  must  be  able  to  reliably  retain  the  audit  data  for  the  amount  of  time 
required  by  the  site. 

The  audit  trail  should  be  reviewed  at  least  once  a  week.  It  is  very  possible  that  once  a  week 
may  be  too  long  to  wait  to  review  the  audit  trail.  Depending  on  the  amount  of  audit  data 
expected  by  the  system,  this  parameter  should  be  adjusted  accordingly.  The  recommended  time 
in  between  audit  trail  reviews  should  be  documented  in  the  Trusted  Facility  Manual. 

8.4  Testing 

The  audit  resources,  along  with  all  other  resources  protected  by  the  TCB,  have  increasing 
assurance  requirements  at  each  higher  Criteria  class.  For  the  lower  classes,  an  audit  trail  would 
be  a  major  factor  in  detecting  penetration  attempts.  Unfortunately,  at  these  lower  classes,  the 
audit  resources  are  more  susceptible  to  penetration  and  corruption.  “The  TCB  must  provide 
some  assurance  that  the  data  will  still  be  there  when  the  administrator  tries  to  use  it.  [3]  The 
testing  requirement  recognizes  the  vulnerability  of  the  audit  trail,  and  starting  with  the  C2 
class,  shall  include  a  search  for  obvious  flaws  that  would  corrupt  or  destroy  the  audit  trail.  If 
the  audit  trail  is  corrupted  or  destroyed,  the  existence  of  such  flaws  indicates  that  the  system 
can  be  penetrated.  Testing  should  also  be  performed  to  uncover  any  ways  of  circumventing  the 
audit  mechanisms.  The  “flaws  found  in  testing  may  be  neutralized  in  any  of  a  number  of  ways. 
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One  way  available  to  the  system  designer  is  to  audit  all  uses  of  the  mechanism  in  which  the 
flaw  is  found  and  to  log  such  events.” [3]  An  attempt  should  be  made  to  remove  the  flaw. 

At  class  B2  and  above,  it  is  required  that  all  detected  flaws  shall  be  corrected  or  else  a  lower 
rating  will  be  given.  If  during  testing  the  audit  trail  appears  valid,  analysis  of  this  data  can 
verify  that  it  does  or  does  not  accurately  reflect  the  events  that  should  be  included  on  the  audit 
trail.  Even  though  system  assurances  may  increase  at  the  higher  classes,  the  audit  trail  is  still 
an  effective  tool  during  the  testing  phase  as  well  as  operationally  in  detecting  actual  or  potential 
security  compromises. 

8.5  Documentation 

Starting  at  the  C2  class,  documentation  concerning  the  audit  requirements  shall  be  contained 
in  the  Trusted  Facility  Manual.  The  Trusted  Facility  Manual  shall  explain  the  procedures  to 
record,  examine,  and  maintain  audit  files.  It  shall  detail  the  audit  record  structure  for  each  type 
of  audit  event,  and  should  include  what  each  field,  is  and  what  the  size  of  the  field  is. 

The  Trusted  Facility  Manual  shall  also  include  a  complete  description  of  the  audit  mechanism 
interface,  how  it  should  be  used,  its  default  settings,  cautions  about  the  trade-offs  involved  in 
using  various  configurations  and  capabilities,  and  how  to  set  up  and  run  the  system  such  that 
the  audit  data  is  afforded  appropriate  protection. 

If  audit  events  can  be  pre-  or  post-selected,  the  manual  should  also  describe  the  tools  and 
mechanisms  available  and  how  they  are  to  be  used. 

8.6  Unavoidable  Security  Risks 

There  are  certain  risks  contained  in  the  audit  process  that  exist  simply  because  there  is  no 
way  to  prevent  these  events  from  ever  occurring.  Because  there  are  certain  unpredictable  factors 
involved  in  auditing,  i.e.,  man,  nature,  etc.,  the  audit  mechanism  may  never  be  one  hundred 
per  cent  reliable.  Preventive  measures  may  be  taken  to  minimize  the  likelihood  of  any  of  these 
factors  adversely  affecting  the  security  provided  by  the  audit  mechanism,  but  no  audit 
mechanism  will  ever  be  risk  free. 

8.6.1  Auditing  Administrators/Insider  Threat 

Even  with  auditing  mechanisms  in  place  to  detect  and  deter  security  violations,  the  threat  of 
the  perpetrator  actually  being  the  system  security  administrator  or  someone  involved  with  the 
system  security  design  will  always  be  present.  It  is  quite  possible  that  the  system  security 
administrator  of  a  trusted  system  could  stop  the  auditing  of  activities  while  entering  the  system 
and  corrupting  files  for  personal  benefit.  These  authorized  personnel,  who  may  also  have  access 
to  identification  and  authentication  information,  could  also  choose  to  enter  the  system  disguised 
as  another  user  in  order  to  commit  crimes  under  a  false  identity. 

Management  should  be  aware  of  this  risk  and  should  be  certain  to  exercise  discretion  when 
selecting  the  system  security  administrator.  The  person  who  is  to  be  selected  for  a  trusted 
position,  such  as  the  system  security  administrator,  should  be  subject  to  a  background  check 
before  being  granted  the  privileges  that  could  one  day  be  used  against  the  employer. 

The  system  security  administrator  could  also  be  watched  to  ensure  that  there  are  no 
unexplained  variances  in  normal  duties.  Any  deviation  from  normal  operations  may  indicate 
that  a  violation  of  security  has  occurred  or  is  about  to  occur. 

An  additional  security  measure  to  control  this  insider  threat  is  to  ensure  that  the  system 
administrator  and  the  person  responsible  for  the  audit  are  two  different  people.  “The  separation 
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of  the  auditor’s  functions,  databases,  and  access  privileges  from  those  of  the  system 
administrator  is  an  important  application  of  the  separation  of  privilege  and  least  privilege 
principles.  Should  such  a  separation  not  be  performed,  and  should  the  admimstrator  be  allowed 
to  undertake  auditor  functions  or  vice-versa,  the  entire  security  function  would  become  the 
responsibility  of  a  single,  unaccountable  individual.” [2] 

Another  alternative  may  be  to  employ  separate  auditor  roles.  Such  a  situation  may  give  one 
person  the  authority  to  turn  off  the  audit  mechanism,  while  another  person  may  have  the 
authority  to  turn  it  back  on.  In  this  case  no  individual  would  be  able  to  turn  off  the  audit 
mechanism,  compromise  the  system,  and  then  turn  it  back  on. 

8. 6. 2  Data  Loss 

Although  the  audit  software  and  hardware  are  reliable  security  mechanisms,  they  are  not 
infallible.  They,  like  the  rest  of  the  system,  are  dependent  upon  constant  supplies  of  power 
and  are  readily  subject  to  interruption  due  to  mechanical  or  power  failures.  Their  failure  can 
cause  the  loss  or  destruction  of  valuable  audit  data.  The  system  security  administrator  should 
be  aware  of  this  risk  and  should  establish  some  procedure  that  would  ensure  that  the  audit  trail 
is  preserved  somewhere.  The  system  security  administrator  should  duplicate  the  audit  trail  on  a 
removable  medium  at  certain  points  in  Time  to  minimize  the  data  loss  in  the  event  of  a  system 
failure.  The  Trusted  Facility  Manual  should  include  what  the  possibilities  and  nature  of  loss 
exposure  are,  and  how  the  data  may  be  recovered  in  the  event  that  a  catastrophe  does  occur. 

If  a  mechanical  or  power  failure  occurs,  the  system  security  administrator  should  ensure  that 
audit  mechanisms  still  function  properly  after  system  recovery.  For  example,  any  auditing 
mechanism  options  pre-selected  before  the  system  malfunction  must  still  be  the  ones  in 
operation  after  the  system  recovery. 
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9.  AUDIT  SUMMARY 

For  classes  C2  and  above,  it  is  required  that  the  TCB  “be  able  to  create,  maintain,  and 
protect  from  modification  or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to 
the  objects  it  protects.” [1]  The  audit  trail  plays  a  key  role  in  performing  damage  assessment 
in  the  case  of  a  corrupted  system. 

The  audit  trail  shall  keep  track  of  all  security-relevant  events  such  as  the  use  of  identification 
and  authentication  mechanisms,  introduction  of  objects  into  a  user’s  address  space,  deletion  of 
objects  from  the  system,  system  administrator  actions,  and  any  other  events,  that  attempt  to 
violate  the  security  policy  of  the  system.  The  option  should  exist  that  either  all  activities  be 
audited  or  that  the  system  security  administrator  select  the  events  to  be  audited.  If  it  is  decided 
that  all  activities  should  be  audited,  there  are  overhead  factors  to  be  considered.  The  storage 
space  needed  for  a  total  audit  would  generally  require  more  operator  maintenance  to  prevent 
any  loss  of  data  and  to  provide  adequate  protection.  A  requirement  exists  that  authorized 
personnel  shall  be  able  to  read  all  events  recorded  on  the  audit  trail.  Analysis  of  the  total  audit 
trail  would  be  both  a  difficult  and  time-consuming  task  for  the  administrator.  Thus,  a  selection 
option  is  required  which  may  be  either  a  pre-selection  or  post-selection  option. 

The  audit  trail  information  should  be  sufficient  to  reconstruct  a  complete  sequence  of 
security-relevant  events  and  processes  for  a  system.  To  do  this,  the  audit  trail  shall  contain  the 
following  information:  date  and  time  of  the  event,  user,  type  of  event,  success  or  failure  of  the 
event,  the  origin  of  the  request,  the  name  of  the  object  introduced  into  the  user’s  address 
space,  accessed,  or  deleted  from  the  storage  system,  and  at  the  B1  class  and  above,  the 
sensitivity  determination  of  the  object. 

It  should  be  remembered  that  the  audit  trail  shall  be  included  in  the  Trusted  Computing 
Base  and  shall  be  accorded  the  same  protection  as  the  TCB.  The  audit  trail  shall  be  subject  to 
strict  access  controls. 

An  effective  audit  trail  is  necessary  in  order  to  detect  and  evaluate  hostile  attacks  on  a 
system. 
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GLOSSARY 


Administrator  -  Any  one  of  a  group  of  personnel  assigned  to  supervise  all  or  a  portion  of  an 
ADP  system. 

Archive  -  To  file  or  store  records  off-line. 

Audit  -  To  conduct  the  independent  review  and  examination  of  system  records  and  activities. 

Auditor  -  An  authorized  individual  with  administrative  duties,  whose  duties  include  selecting 
the  events  to  be  audited  on  the  system,  setting  up  the  audit  flags  which  enable  the  recording 
of  those  events,  and  analyzing  the  trail  of  audit  events. [2] 

Audit  Mechanism  -  The  device  used  to  collect,  review,  and/or  examine  system  activities. 

Audit  Trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of  processing 
used  to  aid  in  tracing  from  original  transactions  forward  to  related  records  and  reports,  and/or 
backwards  from  records  and  reports  to  their  component  source  transactions^  1] 

Auditable  Event  -  Any  event  that  can  be  selected  for  inclusion  in  the  audit  trail.  These  events 
should  include,  in  addition  to  security-relevant  events,  events  taken  to  recover  the  system  after 
failure  and  any  events  that  might  prove  to  be  security-relevant  at  a  later  time. 

Authenticated  User  -  A  user  who  has  accessed  an  ADP  system  with  a  valid  identifier  and 
authentication  combination. 

Automatic  Data  Processing  (ADP)  System  -  An  assembly  of  computer  hardware,  firmware, 
and  software  configured  for  the  purpose  of  classifying,  sorting,  calculating,  computing, 
summarizing,  transmitting  and  receiving,  storing,  and  retrieving  data  with  a  minimum  of  human 
interventional] 

Category  -  A  grouping  of  classified  or  unclassified  sensitive  information,  to  which  an  additional 
restrictive  label  is  applied  (e.g.,  proprietary,  compartmented  information)  to  signify  that 
personnel  are  granted  access  to  the  information  only  if  they  have  formal  approval  or  other 
appropriate  authorization. [4] 

Covert  Channel  -  A  communication  channel  that  allows  a  process  to  transfer  information  in  a 
manner  that  violates  the  system’s  security  policy. [1] 

Covert  Storage  Channel  -  A  covert  channel  that  involves  the  direct  or  indirect  writing  of  a 
storage  location  by  one  process  and  the  direct  or  indirect  reading  of  the  storage  location  by 
another  process.  Covert  storage  channels  typically  involve  a  finite  resource  (e.g.,  sectors  on  a 
disk)  that  is  shared  by  two  subjects  at  different  security  levels.[l] 

Covert  Timing  Channel  -  A  covert  channel  in  which  one  process  signals  information  to  another 
by  modulating  its  own  use  of  system  resources  (e.g.,  CPU  time)  in  such  a  way  that  this 
manipulation  affects  the  real  response  time  observed  by  the  second  process. [1] 

Flaw  -  An  error  of  commission,  omission  or  oversight  in  a  system  that  allows  protection 
mechanisms  to  be  bypassed.[l] 

Object  -  A  passive  entity  that  contains  or  receives  information.  Access  to  an  object  potentially 
implies  access  to  the  information  it  contains.  Examples  of  objects  are:  records,  blocks,  pages, 
segments,  files,  directories,  directory  trees  and  programs,  as  well  as  bits,  bytes,  words,  fields, 
processors,  video  displays,  keyboards,  clocks,  printers,  network  nodes,  etc.[l] 
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Post-Selection  -  Selection,  by  authorized  personnel,  of  specified  events  that  had  been  recorded 
on  the  audit  trail. 

Pre-Selection  -  Selection,  by  authorized  personnel,  of  the  auditable  events  that  are  to  be 
recorded  on  the  audit  trail. 

Security  Level  -  The  combination  of  a  hierarchical  classification  and  a  set  of  non-hierarchical 
categories  that  represents  the  sensitivity  of  information.[l] 

Security  Policy  -  The  set  of  laws,  rules,  and  practices  that  regulate  how  an  organization 
manages,  protects,  and  distributes  sensitive  information.[l] 

Security-Relevant  Event  -  Any  event  that  attempts  to  change  the  security  state  of  the  system, 
(e.g.,  change  discretionary  access  controls,  change  the  security  level  of  the  subject,  change  user 
password,  etc.).  Also,  any  event  that  attempts  to  violate  the  security  policy  of  the  system, 
(e.g.,  too  many  attempts  to  login,  attempts  to  violate  the  mandatory  access  control  limits  of  a 
device,  attempts  to  downgrade  a  file,  etc.).[l] 

Sensitive  Information  -  Information  that,  as  determined  by  a  competent  authority,  must  be 
protected  because  its  unauthorized  disclosure,  alteration,  loss,  or  destruction  will  at  least  cause 
perceivable  damage  to  someone  or  something.!  1] 

Subject  -  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device  that  causes 
information  to  flow  among  objects  or  changes  the  system  state.  Technically,  a  process/domain 
pair .  [  1  ] 

Subject  Sensitivity  Level  -  The  sensitivity  level  of  the  objects  to  which  the  subject  has  both 
read  and  write  access.  A  subject’s  sensitivity  level  must  always  be  less  than  or  equal  to  the 
clearance  of  the  user  the  subject  is  associated  with. [4] 

System  Security  Administrator  -  The  person  responsible  for  the  security  of  an  Automated 
Information  System  and  having  the  authority  to  enforce  the  security  safeguards  on  all  others 
who  have  access  to  the  Automated  Information  System. [4] 

Trusted  Computing  Base  (TCB)  -  The  totality  of  protection  mechanisms  within  a  computer 
system  including  hardware,  firmware,  and  software — the  combination  of  which  is  responsible 
for  enforcing  a  security  policy.  A  TCB  consists  of  one  or  more  components  that  together 
enforce  a  unified  security  policy  over  a  product  or  system.  The  ability  of  a  TCB  to  correctly 
enforce  a  security  policy  depends  solely  on  the  mechanisms  within  the  TCB  and  on  the  correct 
input  by  system  administrative  personnel  of  parameters  (e.g.,  a  user’s  clearance)  related  to  the 
security  policy.!  1] 

User  -  Any  person  who  interacts  directly  with  a  computer  system.!  1] 
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